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ABSTRACT 


This  paper 
interfaces 
4-6,  1980. 
faces  were 


describes  the  proceedings  of 
held  at  the  National  Bureau 
Five  possible 
d iscussad : 


a workshop  on  robot 
of  Standards  on  June 
areas  for  standard i zat ion  of  inter- 
the  Simple  Sensor  interface  between 


simple  peripheral  devices  and  a robot  control  system;  the 
Wrist  Interface,  between  the  robot  wrist  and  the  end  effec- 
tor; the  Complex  Sensor  Interface  that  covers  vision,  com- 
plex touch,  and  other  such  sensors;  the  Common  Robot  Control 
interface,  providing  robot  independent  trajectory  descrip- 
tions; and  Future  Guidelines  towards  Interfaces,  covering 
data  base,  offline  programming,  and  system  integration  in- 
terfaces. The  goal  was  to  define  the  areas  ready  for  current 
standards,  and  those  for  which  standards  would  be  considered 
an  impediment  to  developing  technologies. 


This  workshop  was  jointly  sponsored  by  NBS  and  the  Air  Force 
ICAM  project  under  MIPR  SY1457-00003  "Robotics  Support  Pro- 
ject for  the  Air  Force  ICAM  Program". 
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INTRODUCTION 


On  June  4 - 6»  1980»  a workshop  on  the  need  for  standard i za- 
tion  of  robot  interfaces  was  held  at  the  National  Bureau  of 
Standards  (NBS).  Co-sponsored  by  the  Air  Force  ICAM  office 
and  the  NBS  Programmab le  Automation  group#  the  workshop  was 
co*-chaired  by  Dr.  James  Albus  and  Dr.  Roger  Nagel  of  the 
NB^.  Mr.  Gordon  Mayer  of  the  Air  Force  ICAM  presented  an 
over-view  of  the  Air  Force  program  in  robotics  both  present 
and  future.  There  were  35  attendees  representing  industry# 
academia#  and  the  government.  During  the  workshop#  the  at- 
tendees were  assigned  to  one  or  more  of  five  separate  work- 
ing groups#  each  of  which  met  on  two  occasions.  These  five 
areas  were:  the  Simple  Sensor  interface  between  simple  peri- 
pheral devices  and  a robot  control  system;  the  Wrist  Inter- 
face# between  the  robot  wrist  and  the  end  effector#  the  Com- 
plex Sensor  Interface  that  covers  vision#  complex  touch#  and 
other  such  sensors#  the  Common  Robot  Control  interface#  pro- 
viding robot  independent  trajectory  descriptions#  and  Future 
Guidelines  towards  Interfaces#  covering  data  base#  offline 
programming#  and  system  integration  interfaces.  There  were 
general  sessions  held  each  day  both  to  charge  the  separate 
working  groups  with  tasks  and  to  hear  reports  on  their 
results  so  that  the  workshop  could  truly  function  in  an  in- 
teractive working  fashion. 

On  the  last  day  of  the  workshop#  a general  session  was  held. 
At  that  session  it  was  determined  that  with  respect  to  the 
Simple  Sensor  interface#  connecting  robots  with  other  dev- 
ices in  their  environment#  the  time  has  come  when  standards 
ought  to  be  created.  Similarly#  with  respect  to  the  Wrist 
interface#  the  connection  between  the  robot  wrist  and  its 
end  effector#  we  are  also  ready  for  a standard.  In  both  of 
these  areas  ’•eports  were  written  recommending  the  beginning 
of  a standards  effort. 

With  respect  to  the  Complex  Sensor  and  Common  Robot  Control 
interfaces#  it  was  determined  that  it  is  still  too  early  to 
begin  a standards  effort.  However#  position  papers  arguing 
for  particular  directions  and  general  awareness  of  the  com- 
munity on  these  topic  areas  have  been  written  and  are  in- 
cluded in  this  report.  These  position  papers  are  designed  to 
focus  attention  on  the  issues  and  suggest  paths  as  to  how 
they  may  be  addressed. 

In  the  fifth  topic  area#  Future  Guidelines  towards  Inter- 
faces# the  two  main  trhemes  covered  were  robot  programming 
languages  and  the  integration  of  robots  into  robotic  systems 
for  automated  manufacturing.  While  the  discussions  were 


-7- 


interesting  and  instructive#  it  was  clear  that  it  is  much 
too  early  in  the  development  of  these  areas  to  offer  stan- 
dards. The  general  feeling  was  that  the  field  is  beginning 
to  accelerate  and  that  it  would  be  worth  re-investigating 
these  topics  as  well  as  some  of  the  other  topics  covered  in 
the  workshop  in  approx imately  one  year.  Accordingly#  the 
Bureau  of  Standards  and  the  Air  Force  ICAM  office  are  look- 

possibility  of 


ing  into 
place  next 


the 

June. 


a second  conference  to  take 


WORKSHOP  REPORTS 


During  the  introductory  workshop  session*  guidelines  were 
drawn  up  for  a format  for  each  workshop  session  to  follow. 
Various  topics  and  questions  were  to  be  presented  to  the 
group  members*  and  answered  as  best  befits  that  interface. 
The  topics  decided  upon  for  discussion  were! 

A.  Scope  and  Definition  of  Interface 

B.  Is  There  a Need  for  a Standard? 

C.  Standard! nation 

D.  Timing  of  Effort 

E.  Recommendations 

Following  these  initial  discussions*  the  overall  group  broke 
out  into  the  individual  working  groups.  The  session 
chairpersons  were  charged  with  reporting  the  activities  of 
their  particular  group  with  respect  to  these  questions*  and 
to  draw  up  a position  paper  on  their  conclusions  and  recom- 
mendations at  the  close  of  the  workshop.  Their  reports  are 
below  in  the  following  order:  the  Simple  Sensor  interface* 

the  Wrist  interface*  the  Common  Robot  Control  interface*  the 
Complex  Sensor  interface*  and  the  Future  Guidelines  towards 
Interfaces  report. 


SIMPLE  SENSOR  INTERFACE 


I.  GROUP  MEMBERS 


Bryan  Dawson  * 
Richard  Becker 
Edwin  Bowerman 
Donald  Caughman 
John  Dexheimer 
Bruce  Ernst 
Patrick  Hacker 
Ward  McLure 

* Chairperson 


Cincinnati-  Milacron 
Cheeseborough  - Ponds*  Inc. 
GTE  Laboratories 
Lockheed  - Georgia  Company 
General  Electric 
Prab  Conveyors*  Inc. 

Boeing 

Texas  Instruments 


II.  INTRODUCTION 

In  the  general  introduction  to  the  workshop*  it  was  stated 
that  this  type  of  interface  was  probably  one  of  those  most 
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ready  for  standard i zat ion.  This  group  session  was/  there- 
fore! charged  with  addressing  certain  specific  issues  with 
regard  to  the  possible  standarrfi zation  of  robot-to- 
peripheral  device  interfaces  and  to  offer  guidelines  towards 
topics  to  be  addressed  in  such  a standard. 


III.  DEFINITION  OF  A PERIPHERAL  DEVICE 

A peripheral  device  in  this  context  was  defined  as  a piece 
of  equipment  or  device  used  in  conjuction  with  an  industrial 
robot  in  the  implementation  of  an  application#  and  which 
communicates  with  the  robot  by  means  of  binary  signals  only. 
To  set  the  record  straight#  it  does  not  include  what  are  re- 
ferred to  as  computer  peripheral  devices  such  as  floppy 
discs#  printers#  and  other  such  devices. 

The  definition  should  also  not  be  construed  to  include 
higher  frequency  binary  signals  which  constitute  a data  for- 
mat# nor  analog  signals.  However#  many  of  the  areas  dis- 
cussed by  this  group  could  also  apply  to  such  interfaces. 
Examples  of  peripheral  devices  would  be  machine  tools#  spot 
weld  equipment#  conveyors#  etc. 


IV.  IS  THERE  A NEED  FOR  A STANDARD? 

The  consensus  of  the  group  was  "yes"  and  the  time  for  imple- 
mentation is  just  right  or  may  be  even  too  late.  The  follow- 
ing reasons  for  this  conclusion  were  offered; 

A.  Many  robot  users  require  the  interfacing  of  robots  to 
older#  existing  in-plant  equipment.  It  is  not  until  the  ac- 
tual interfacing  takes  place  that  snags#  such  as  the  follow- 
ing# are  found; 

1.  Lack  of  interface  points  on  old  equipment. 

2.  Lack  of  control  devices  such  as  limit  switches  on 
existing  machines. 

3.  Lack  of  complete  cycle  control  on  existing  equip- 
ment# e.  g.  # no  way  of  initiating  an  automatic  cycle  nor 
of  generating  a cycle  complete  signal. 

In  other  words#  up  until  just  recently#  machines  and  equip- 
ment have  not  been  built  with  robots  in  mind. 

B.  To  offset  these  problems#  there  is  a need  to  aid  the 
user#  robot  manufac turer # and  peripheral  equipment  manufac- 
turer by  providing  guidelines  to  indicate  the  requirements 
for  adequate  marriage  of  the  equipment. 
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C.  It  was  felt  that 
ing  manufactured 
need  to  standardize 

D.  Although  new  eq.u 
with  robots*  it  i 
years*  robots  will 
“old"  equipment. 


although  new  per 

ipheral 

equipment 

is 

be- 

o  be 

used  with 

robots* 

there  is 

st  i 

ll  a 

log  ic 

levels  of 

signals 

• 

pment 

is  being 

made  s 

uitable  f 

or 

use 

envi 

saged  that 

for  at 

least  the 

ne  X 

t 20 

till 

be  required 

. to  interface  wi 

th 

the 

V.  RECOMMENDATIONS 

The  group  decided  to  limit  the  scope  of  guidelines  to  in- 
clude the  following  subjects:  signal  level  and  type*  noise 
and  means  of  elimination*  connector  configurations*  minimum 
interlock  signal  requirements*  and  incorporation  of  existing 
standards. 

A.  Signal  Level  and  Type 

Existing  equipment  and  plants  often  use  110  V/AC  relay  logic 
type  control.  Naturally*  it  is  usually  not  possible  to 
change  these.  Therefore*  a 110  VAC  interface  appears  to  be 
necessary.  New  equipment  (and  programmable  controllers) 
tend  towards  the  use  of  lower  voltage  solid  state  logic* 
therefore  a 24  VDC  interface  also  appears  to  be  necessary. 
It  was  felt  that  for  this  type  of  interface*  levels  such  as 
the  5 VDC  were  too  low  and  included  possible  noise  and  line 
attenuation  problems.  Thus  (in  conjunction  with  common  prac- 
tice) the  two  logic  levels*  24  VDC  and  110  VAC*  were  put 
forth  as  guidelines. 


B.  Noise  and  means  of  elimination 


Precautions  must  be  taken  to  eliminate  the  effects  of  noise* 
voltage  transients*  contact  bounce*  etc.  The  following 
points  were  indicated  as  guidelines  to  eliminating  these 
problems. 

1.  Adequate  grounding  to  eliminate  ground  loops. 

2.  Suitable  shielding*  e. g. * basketweave*  twisted 
shielded  pair  signal  lines*  etc. 

3.  Eliminating  contact  bounce  and  similar  effects  in 
devices  such  as  relays  and  limit  switches  by  suitable 
damping  or  by  time  delay  concepts  in  robot  controls. 

4.  Devices  need  to  be  isolated*  e. g.  * by  optical  cou- 
p 1 ing. 

5.  Noise  from  switching  devices  can  be  eliminated  by 
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suitable  arc 


suppression. 


on»  i. e. . floating  zero  po- 
(not  tied  to  ground). 


6.  Dif-ferent ial  communicati 
tential  on  one  signal  line 

7.  Control  power  should  be 

8.  Solid  state  devices  may 
resistors  to  ensure  proper 


from  isolated  utilities. 

require  such  things  as  load 
signal  recognition. 


C.  Connector  Configurations 


Field  wiring  to  terminal  strip  interface  boxes  was  recom- 
mended. The  interface  terminal  boxes  must  be  mounted  to  the 
robot  control  and  peripheral  equipment  such  that  the  termi- 
nal strip  access  is  convenient.  The  field  wiring  should  be 
done  in  hard  conduit  for  noise  rejection.  Use  of  individual 
pairs  of  wires  from  the  robot  to  different  parts  of  peri- 
pheral equipment  was  not  recommended. 

Also  recommended  was  the  use  of  pre-assemb led  flexible  con- 
duit and  connectors  for  connections  to  and  from  junction 
boxes.  Such  connectors  in  common  use  are  Pyle  National/  Am- 
phenol# Cannon/  etc./  and  are  usually  user  specified. 

A combination  of  the  above  may  be  used.  If  a combination  of 
110  VAC  and  PA  VDC  is  used#  the  signal  lines  must  be  ade- 
quately separated. 

D.  Minimum  Interface  Requirements 

A minimum  interlock  requirement  is  probably  necessary.  The 
attached  diagram  (Figure  1)  shows  such  interface  signals. 
However/  the  signals  and  their  functions  are  very 
application-oriented  and  each  application  must  be  examined 
carefully. 

E.  Existing  Standai'ds 

Ulherever  possible#  existing  standards  should  be  used#  if  not 
in  their  entirety#  at  least  as  guidelines.  For  instance# 
some  robot  manufacturers  and  users  have  already  formulated 
their  own  standards.  Programmable  controller  users  and 
manuf acturer s similarly  may  have  their  own  common  practices. 
A standards  search  for  such  information  is  recommended. 


VI.  GENERAL  COMMENTS  AND  CONCLUSIONS 

It  was  recognized  that  in  many  cases  effective  use  of  pro- 
grammable controllers  would  bridge  the  gap  between  "old" 
equipment  and  robots#  and  would  also  allow  "add  on"  cycle 
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OUTPUTS  FROM  ROBOT  OUTPUTS  FROM  PERIPHERAL  DEVICE 


FIGURE  I 

Minimum  Robot/Peripheral  Device 


.1 


control  to  such  equipment.  Houieveri  the  guidelines  discussed 
above  still  apply.  Many  of  these  guidelines  could  also  ap- 
ply to  the  other  interfaces  discussed  in  the  workshop  as 
well  as  to  analog  signals  between  equipment. 
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UR  1ST  INTERFACE 


I.  GROUP  MEMBERS 


Dunne*  Maurice-* 
Smith*  Bradford  M.  * 


Uni mat ion 

National  Bureau  of  Standards 
McDonnell  Douglas 
Prab  Conveyors*  Inc. 

General  Dynamics 
RCA 

Naval  Surface  Ueapons 


Ennis*  Jerry 
Ernst*  Bruce 
Handuierg*  R.  J 
Potter*  Louis 
Vranish*  John 


*Co-Chairperson 


II.  INTRODUCTION 


Robots  have  typically  been  applied  in  dedicated*  high-volume 
tasks  where  only  a single  gripper  or  end  effector  has  been 
required.  The  end  effector  is  generally  a unique  design  and 
is  specifically  built  for  the  chosen  task  by  either  the 
manufacturer  or  the  end  user.  If  subsequent  end  effectors 
are  needed*  the  user  is  often  hard  put  to  find  sources  with 
reasonable  leadtimes  and  costs.  Manuf ac turer s are  necessari- 
ly more  interested  in  expanding  their  sales  of  similar 
robots  than  they  are  in  taking  on  more  design  and  fabrica- 
tion of  different  end  effectors.  Other  design  engineering 
firms  are  unable  to  develop  cost-effective*  generic  end  ef- 
fectors since  mounting  techniques  vary  across  different 
robot  models  and  the  volume  of  any  one  configuration  is 
fairly  small. 

Present  mounting  schemes  allow  for  manual  replacement  of  an 
end  effector  and  actuation  of  its  operating  mechanism.  These 
schemes  generally  involve  a bolt-on  technique  with  facili- 
ties for  hydraulic*  pneumatic*  and/or  electrical  signals  to 
and  from  the  end  efPector.  One  problem  sometimes  encountered 
with  these  designs  is  that  an  end  effector  cannot  be  re- 
placed in  exactly  the  same,  position  and  orientation  that  it 
had  originally.  This  forces  a user  to  slightly  reprogram  his 
robot  every  time  an  end  effector  such  as  a gripper  or  spot 
weld  gun  is  taken  off  for  maintenance.  Another  problem  seen 
by  users  of  a variety  of  different  robots  is  that  end  effec- 
tors are  not  exchangeable  across  like  capability  manipula- 
tors. Often  a spare  unit  must  be  stocked  for  each  different 
production  robot. 

Recent  trends  have  seen  robots  used  for  a greater  variety  of 
small-volume  workloads.  Here*  end  effectors  are  often 
changed  to  meet  new  job  requirements  or  to  make  use  of  a 
variety  of  tools  -Por  the  same  job.  Increased  emphasis  is 
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placed  on  the  interface  between  th 
effector.  Designs  are  required 
its  own  tools  on  command.  Several 
to  exist  with  at  least  one  in  the 


e robot  wrist  and  the  end 
whereby  a robot  can  change 
implementations  are  known 
public  domain. 


III.  NEED 


The  Group  concluded  early  in  their  discussion  that  it  was 
timely  to  initiate  a standard i zation  activity  to  address  the 
interface  between  an  industrial  robot  and  the  variety  of  end 
effectors.  Areas  to  be  covered  include  mechanical  registra- 
tion; fastening;  and  facilities  for  air#  fluid*  and  electri- 
cal signals  to  and  from  the  end  effector.  Furthermore*  a 
standard  for  the  mounting  surface  would  provide  the  follow- 
ing benefits: 


-A  user  can  put  the  same  gripper  on  any  of  his  robots 
without  redesign  and  rework. 


-A  user  can  replace  a worn  or  damaged  gripper  without 
editing  or  reprogramming. 


-A  user  can  purchase  a gripper  from  a specialty  sup- 
plier with  assurance. 


IV.  INTERFACE  REQUIREMENTS 


The  wrist/end  effector  interface  design  addresses  a variety 
of  engineering  concerns: 

A.  Mechanical  Fastening 

The  wrist  mounting  surface*  to  which  the  end  effector 
is  attached*  must  withstand  rated  static  and  dynamic 
loads. 

B.  Registration  and  Orientation 

Facilities  must  be  provided  for  locating  the  end  effec- 
tor in  the  same  attitude  each  time  it  is  mounted. 

C.  Electrical  and  Pneumatic 

Capability  for  actuators*  powered  tools  and  sensors  on 
the  end  effector  will  require  connections  for  electri- 
cal* electronic*  hydraulic  and  pneumatic  lines. 

D.  Replaceable  or  Quick  Change 

All  applications  require  means  for  users  to  remove  an 
end  effector;  some  require  the  robot  to  change  tools 
itself. 
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V.  STANDARDIZATION 


A logical  stepwise  progression  was  developed  by  the  working 
group  through  which  standard i zat ion  of  the  wrist  interface 
could  be  obtained.  The  strategy  was  suggested  to  start  with 
the  development  of  a common  mounting  surface  for  functional- 
ly equivalent  robots.  The  surface  will  provide  for  fasten- 
ing* registration  and  indexing  of  end  effectors.  Envisioned 
here  is  perhaps  the  disk  shaped  mounting  surface  shown  in 
Figure  1 which  incorporates  a bolt  circle  for  fastening*  a 
land  for  shear  strength  and  registration*  and  a pin  for  in- 
dexing. The  bolt  circle  might  be  on  the  order  of  six  inches 
in  diameter  for  a large  class  of  robots  and  include  a four- 
inch  and  a two— inch  size  to  cover  smaller  classes  of  robots. 
It  is  important  to  note  that  the  interior  of  the  circle  is 
undefined  allowing  manuf ac turers  leeway  in  incorporating 
this  design  into  their  product. 

A second  step  in  the  strategy  is  to  attack  the  problem  of 
passing  signals  and  power  through  the  interface.  Various  al- 
ternatives were  suggested  leading  to  the  only  conclusion 
that  the  mechanical  concept  imposed  no  unrealistic  con- 
straints on  the  electrical/pneumatic  problem  and  the  latter 
was  best  left  to  a working  group  of  design  engineers  under 
the  standard i zat ion  effort. 

The  last  step  in  the  strategy  is  to  address  the  quick  change 
problem.  At  least  three  designs  are  known  to  exist  with  one 
developed  under  Air  Force  ICAM  funding  and  being  available 
to  any  user.  However*  it  was  thought  premature  at  this  time 
to  initiate  standard i zation  activity  in  the  quick  change 
area  since  the  variety  of  signals  to  and  from  the  end  effec- 
tor are  so  diverse  in  present  applications  that  a consensus 
for  standard i zat ion  does  not  yet  exist.  A conclusion  was 
made  that  a future  standard  for  a quick  change  device  is 
highly  desirable  and  it  is  hoped  that  the  experience  gained 
in  the  above  two  areas  by  the  standards  group  will  pave  the 
way  for  needed  work  on  the  quick  change  mechanism. 

V I . RECOMMENDAl I ONS 


To  initiate  standard i zation  activity  in  this  area  the 
ing  group  developed  a letter  request  to  the  Robotics 
tute  of  America  for  sponsorship  of  a group  to  develop 
mon  interface  between  the  robot  and  the  end  effec 
functionally  equivalent  classes  of  industrial  robots 
letter  outlined  the  scope*  overview  and  need  for  te 
work.  It  was  recommended  initially  that  activity  be 
ed  at  establishing  a bolt-on  mounting  surface  whi 
provide  registration  and  indexing.  Consideration  cou 
be  given  to  Future  requirements  for  utility  servi 
quick  change  requi rements. 
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UNDEFINED  AREA 


Land 


FIGURE  1 


Typical  Mounting  Surface  Geometry 
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One  of  the  first  tasks  of  any  such  effort  would  be  to  gather 
data  on  all  U.  S.  Robotic  mounting  surfaces  presently  used. 
In  an  effort  symbolic  of  the  perceived  need  for  standard i za~ 
tion  in  this  av'ea#  representatives  from  each  robot  vendor 
offered  to  make  available  the  engineering  drawings  of  their 
mounting  surface.  These  are  included  as  Appendix  I. 


VII.  CONCLUSIONS 

The  present  variety  of  grippers  and  end  effectors  is  extreme 
and  will  probably  continue  to  proliferate.  While  the  robot 
manufacturer  will  provide  design  and  manufacture  of  a spe- 
cial gripper  as  an  initial  service*  his  interests  lie  in  the 
serial  production  of  robots  and  not  in  the  fabrication  of 
single  quantities  of  widely  varying  end  effectors.  The  bur- 
den is  falling  increasingly  on  the  user  to  design  his  own. 
While  the  rapid  expansion  of  robots  in  the  work  force  pro- 
vides a total  volume  which  could  support  an  independent 
business  concerned  with  the  design  and  manufacture  of  robot 
end  effectors*  it  is  not  yet  viable  since  the  method  of  at- 
tachment varies  so  widely  among  manufacturers.  An  adequate 
interface  standard  would  be  a most  timely  solution  benefit- 
ing both  vendors  and  users. 
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COMMON  ROBOT  CONTROL  INTERFACE 


I.  GROUP  MEMBERS 


Barbera#  Anthony  J. 

National  Bureau  of  Standards 

Spaulding#  Charles* 

- 

Uni mat ion 

Ames#  Carl  V. 
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General  Dynamics 

Baird#  Henry  S. 

- 

RCA 

Colleen#  Hans 
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ASEA 

Dawson#  Brian 
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Cincinnati-Milacron 

Dexheimer#  John 
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General  Electric 

Dunne#  Maurice 

- 

Unimat ion 

Makhlin#  A.  G. 

- 

West inghouse 

Mayer#  Gordon 

- 

Wr  igh t-Patterson 

Plumley#  Ually 
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Charles  S.  Draper 

VanderBrug#  Gordon 
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Automat i X 

Uheatley#  Thomas  - 

* Co-Chairperson 

National  Bureau  of  Standards 

II.  INTRODUCTION 


This  uorking  group  considered  the  specifications  of  a 
robot-independent  control  interface  that  would  allow  for 
real-time  trajectory  control  of  a robot.  Such  an  interface 
would  provide  the  option  of  controlling  the  robot  with  a 
user  program  generated  external  to  the  manufac turer 's  con- 
troller! where  the  robot^s  motions  would  be  specified  in 
some  robot-independent  form  (e. g.  Cartesian  descriptions  of 
the  end  effector's  position  and  orientation).  In  consider- 
ing this  interface#  the  following  topics  were  discussed: 


1. 

2. 

3. 

4. 

5. 


The 

The 

the 

The 

The 

The 


need  for  such  an  interface. 

level  within  the  control  structure  at  which 
interface  should  occur. 

scope  of  the  interface  specification. 

possible  standard i zat ion  of  the  interface. 

timing  of  the  interface,  specification  effort. 


i 
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III.  THE  NEED  f-OR  I HE  INTERFACE 


To  better 
of  robot 
here. 


understand  the  question  of 
interface*  some  background 


the  need  for  this  type 
information  is  included 


A.  Background 

Industrial  robots  are 
some  combination  of 
rotary-jointed  linkag 
quired  to  be  able 
any  point  in  space  uii 
cussed  here  is  meant 
joints.  To  establish 
cussion  different  1 
described. 


mechanical  manipula 
prismatic  (telescopi 
es.  A minimum  of  si 
to  position  the  robot 
th  any  orientation, 
to  provide  a means  of 
common  dialog  for  th 
evels  of  control  ca 
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1.  Servo  System 

The  more  general-purpose  industrial  robots  have  their 
joint  motions  under  servo  control.  The  inputs  to  the 
servo  control  are  the  desired  joint  positions  of  the 
robot.  Ihese  are  compared  to  the  feedback  from  the 

joint  position  indicators.  If  these  values  are  dif- 
ferent* a drive  signal  is  generated  to  move  each  joint 
until  the  position  error  is  nulled  in  a smooth*  stable 
manner.  1his  bottom  level  of  control  exists  in  all 

general  purpose*  programmable  robots. 

2.  Joint-Space  Coordinates 


The  joint  position  values  that  are  input  to  the  servo 
system  are  the  coordinates  in  the  joint  space  of  the 
robot  uihich  describe  some  desired  position  and  orienta- 
tion of  the  manipulator. 

Different  robots  within  and  between  manufacturers  are 
made  with  different  size  links  and  different  combina- 
tions of  prismatic  and  rotary  joints.  Thus  two  dif- 
ferent robots  capable  of  performing  the  same  task  of 
manipulating  an  end  effector  through  the  same  trajec- 
tories* positions*  and  orientations  could  have  very 
different  mechanical  configurations.  <See  Fig  1. ) 
Therefore*  the  sequence  of  joint  position  coordinates 
for  two  such  robots  would  be  very  different  even  though 
they  were  moving  an  end  effector  through  the  same  tra- 
jectory in  space.  Even  two  robots  of  the  same  type 
from  the  same  manufacturer  would  require  different 
joint  position  coordinates  due  to  lack  of  exactly  the 
same  zero  location  of  position  indicators*  different 
tolerances  in  linkage  alignment*  slightly  different 
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FIG  1 Example  of  how  two  different  robot  configurations 
can  position  an  end  effector  in  the  same  location  and 
orientation.  The  joint  values  are  very  different 
between  the  two  robots  while  the  end  effector's  location 
in  both  instances  can  be  described  by  the  same  set  of 
robot-independent  work  space  coordinates. 


linkage  length#  etc 


The  lack  of  compatibility  between  the  joint-space  coor- 
dinates of  one  robot  with  those  of  another  robot  does 
not  pose  a problem  with  robots  used  in  stand-alone# 
teach-record-p layback  app 1 icat ions.  This  is  because 
the  joint-space  coordinates  played  back  to  the  robot 
are  the  values  recorded  off  the  same  robot  while  it  was 
being  physically  led  through  the  task  motions.  Howev- 
er# these  recorded  joint  values  could  not  be  played 
back  through  another  robot  and  result  in  the  same  tra- 
jectories for  the  reasons  mentioned. 


3.  Cartesian-Gpace  Coordinates 

The  joint-space  coordinates  of  a robot  describe  motions 
of  the  rotary  and  sliding  joints  of  the  particular 
robot  involved.  There  are  times#  however#  when  it  is 
advantageous  to  be  able  to  command  motion  of  the 
robot's  end  effector  in  some  other  coordinate  system. 
Programming#  traject^ory  control#  and  path  modification 
using  sensory  feedback  are  all  more  easily  commanded  in 
coordinate  systems  other  than  joint  coordinates  of  the 
robot.  For  example#  it  is  simpler  for  an  operator  to 
move  the  end  effector  to  desired  locations  if  she  is 
commanding  end  effector  motions  in  an  X# Y# Z frame  of 
reference  (e. g.  with  a joystick)#  rather  than  trying  to 
move  each  joint.  (See  Fig  2.  ) 


Motion  commands  can  be  given  in  any  arbitrary 
nate  frame  of  reference  as  Long  as  there  ex 
necessary  coordinate  transf ormat ion  algorithms 
culate  the  corresponding  joint  position  val 
will  result  in  the  proper  joint  motions.  Eac 
must  have  a coordinate  transf ormation  routine 
larized  to  its  linkage  and  joint  conf igurat ion# 
as  the  zero  points  and  resolution  of  the  joint 
indicators. 
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A set  of  values  in  an  arbitrary  coordinate 
as  a Cartesian  coordinate  system  based 
place#  is  a robot-independent  description 
tion  and  orientation  of  the  robot's  end  e 
Fig  3.  ) The  coordinate  transf ormation  r 
into  a robot  control  system  will  take  th 
values  and  transform  them  into  the  corresp 
joint  position  values  for  that  robot. 
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B.  Controllers  and  Control  Systems 

When  a user  purchases  an  industrial  robot#  he  also  receives 
a controller  which  contains  some  form  of  control  system  that 
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FIG  2 This  figure  illustrates  the  required  coordination 
of  a number  of  joints  in  order  to  obtain  a straight  line 
motion  of'  the  hand.  For  each  incremental  move  along  the 
straight  line  path,  joints  J2  (elevation),  J3  (boom  ex- 
tension), and  Jb  (wrist  flex)  must  be  adjusted  and  coor- 
dinated. 
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FIG  3 This  figure  depicts  the  specification  of  the  po-  « 

sition  and  orientation  of  the  end  effector  by  3 sets  of  ff 

workspace  robot-independent  Cartesian  coordinates.  T 

There  is  an  x,y,z  location  to  specify  the  wrist  point, 

an  x,y,z  location  to  specify  the  end  point  and  an  x,y,z 

location  to  specify  the  finger  tip.  These  would  be  the 

same  values  regardless  of  tne  type  of  robot  used.  The 

coordinate  transformation  algorithms  will  calculate  the 

set  of  joint  values  ( J 1 , J2  , J 3 , J 4 , J5  , J6  , J 7 ) required  to 

position  this  particular  robot  in  the  correct  way  to  put 

the  end  effector  in  the  specified  configuration. 


includes  a programming  and  execution  capability.  The  user 
does  not  have  direct  input  capability  to  the  actuators*  the 
servos*  or  to  a coordinate  transf ormat ion  routine.  Rather# 
the  robot  manufacturer  has  provided  in  the  controller  a user 
interface  for  programming  a task  to  be  performed.  Once  a 
task  is  programmed#  the  controller  can  be  put  into  an  execu- 
tion mode  in  which  the  rohot  moves  through  the  recorded  tra- 
jectories. The  following  describes  the  type  of  programming 
required  and  the  level  of  control  capability  available  with 
typical  systems. 


Joint-Space  Controllers 


The  simplest  form  of  controllers  available  on  servoed 
robots  use  a control  system  that  is  totally  based  in 
joint-space  coordinates.  These  controllers  are  typi- 
cally the  teach-record-playback  type.  A robot  with 
such  a controller  is  programmed  by  moving  the  joints 
using  individual  joint  control  buttons  until  the  robot 
is  in  a conf iguration  that  places  the  end  effector  in 
the  required  location  and  orientation  for  a desired 
trajectory  point  in  the  program.  This  position  is 
recorded  by  reading  in  and  storing  the  values  from  the 
joint  position  indicators  on  the  robot  A sequence  of 
these  points  is  programmed  and  recorded  in  this  manner. 
To  have  the  robot  repeat  this  sequence#  the  controller 
is  put  into  execution  mode  which  simply  causes  the 
recorded  joint  values  to  be  played  back  in  the  correct 
order  and  timing  to  the  servo  system.  As  the  set  of 
joint  values  that  define  each  location  are  input  to  the 
servos#  the  joints  move  to  these  specified  positions. 
When  the  joints  have  moved  to  within  a predefined  delta 
value  of  their  commanded  positions#  the  next  set  of 
joint  values  is  sent  to  the  servos.  Different  se- 
quences of  such  joint  coordinates  can  be  recalled  from 
memory  and  played  through  the  execution  mode  of  the 
controller  causing  the  robot  to  perform  different 
prerecorded  tasks.  However#  as  mentioned  above#  a 
stored  program  taught  on  one  robot  cannot  be 
transferred  to  another  robot  and  have  the  same  task 
trajectories  executed.  Nor  is  there  an  interface  to 
the  robot's  servo  system  that  allows  the  user  to  input 
a separately  generated  set  of  joint  position  values. 
(This  would  he  desirable#  for  example#  if  the  user  pro- 
vided a separate  coordinate  transf ormat ion  processor  to 
calculate  joint  position  values  from  sets  of  Cartesian 
coordinates.  > 


Joint-space  controllers  pr 
and  algorithms  to  allow 
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physically  moved  in  order  to  record  the  joint  position 
values. 

2.  Coord inate -Transformat ion  Controllers 

Several  robot  controllers  are  equipped  with  sufficient 
computational  capability  to  calculate  the  transforma- 
tion from  some  defined  coordinate  system  to  the  joint 
coordinates  of  the  particular  robot.  These  controllers 
allow  the  user  to  program  straight-line  motions#  mo- 
tions about  a tool  point  axis#  and  other  trajectories 
which  reference  some  relatively  robot-independent  coot — 
dinate  system.  Programming  becomes  a simpler  and 

easier  task  since  the  operator  can  move  the  robot  into 
position  using  a joystick#  or  other  means#  which  com- 
mand motions  of  the  end  effector  directly.  Motions  up# 
down#  sideways# and  rotations  about  a tool  tip  are  all 
commanded  in  a straigh tf orward  and  simple  fashion.  The 
necessary  joint  coordination  is  provided  through  the 
coordinate  transf ormat ion  algorithms.  Again#  the  con- 
troller provides  programming  and  execution  capabili- 
ties# but  still  does  not  provide  a user  interface  into 
either  the  coordinate  transf ormat ion  calculations  or 
the  joint-position  inputs  to  the  servos.  Rather#  these 
are  stand-alone  controller-robot  systems  that  are  used 
to  teach  their  own  programs  and  execute  them. 


There  are  two  major  differences  between  these  controll- 
ers and  the  joint-space  controllers  mentioned  previous- 
ly. First#  coord inate-transf ormation  controllers  ease 
programming  since  coordinated  joint  motions  are  com- 
manded in  workplace  or  tool  coordinates  rather  than  the 
operator  having  to  coordinate  various  joints  through 
individual  joint  motions.  Second#  these  controllers 
also  provide  a higher  degree  of  trajectory  control  dur- 
ing execution.  That  is#  even  though  the  programming 
still  consists  of  recording  only  the  end  points  of  the 
trajectories#  the  executed  trajectories  can  be 
straight  lines  rather  than  the  arc  type  motions  about 
the  rotary  joints  that  are  seen  with  the  joint  space 
controllers.  This  straight  line  motion  is  due  to  the 
real-time  computation  of  the  coordinate  transforma- 
tions. The  end  points  are  stored  in  the  form  of  some 
workspace  coordinates  such  as  Cartesian#  cylindrical  or 
spherical.  Intermediate  trajectory  points  are  calcu- 
lated during  execution  and  transformed  to  the 
corresponding  robot  joint  coordinate  values.  This 
results  in  c ontrol led-tra jectory  motion  in  the 
workspace  coordinate  system. 


Uhile  this  type  of  controller  provides  enhanced  capa- 
bilities over  the  joint-space  controllers#  it  still 
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limits  the  user  to  only  that  set  of  manufacturer  sup- 
plied features. 

3.  Higher-l.evcl  Programmable  Controllers 

In  general*  the*  differences  between  the  joint-space 
controllers  and  the  coord inate-transf ormat ion  controll- 
ers has  been  the  inclusion  of  extensive  computing  capa- 
bilities. As  the  manufacturers  increase  the  amount  of 
real-time  processing  in  their  controllers*  additional 
features  can  be  incorporated.  These  could  include  tra- 
jectory optimization;  trajectory  smoothing  through  in- 
termediate points*  user-specified  acceleration  and  de- 
celeration profiles*  trajectory  modification  based  on 
sensory  feedback  data;  off-line  programming  of  trajec- 
tories without  requiring  the  robot  to  move  through  the 
points  in  a teach  mode*  real-time  branching  to  alter- 
nate routines  to  cope  with  varying  situations  and  error 
conditions*  self  diagnosis*  etc. 

It  is  t-he  addition  of  the  computer  to  the  industrial 
robot  manipulator  that  is  resulting  in  a truly  general 
purpose  programmable  automation  device  with  extensive 
features  and  capabi 1 i ties.  Indeed*  the  computer  has 

created  so  many  possible  additional  capab i 1 it ies*  that 
no  one  controller  would  be  able  to  provide  all  of  them. 
This  is  why  it  is  important  for  interfaces  to  be  pro- 
vided to  these  controllers  so  that  the  full  advantages 
of  computer  control  can  be  realized.  If  the  controller 
does  not  provide  a certain  function*  such  as  trajectory 
modification  using  a particular  sensor's  feedback*  and 
there  is  no  interface  into  the  system  to  accept  this 
type  of  functional  input  from  a user-supplied  computer 
system*  then  the  robot  will  not  be  able  to  incorporate 
this  capability.  With  the  proper  interfaces  into  the 
manufacturer 's  controller*  however*  the  robot's  poten- 
tial capabilities  can  be  fully  realized. 

C.  Advantages  of  Robot-Independent  Interface 

The  following  is  a description  of  some  of  the  advantages 

that  would  be  provided  by  a robot-independent  control  inter- 
face. 

1.  Interchangeab i 1 ity 

A robot-independent  control  interface  would  provide  the 
capability  of  interchangab ity . For  example*  one  robot 
could  be  physically  removed  from  a work  area  (for 
repairs  for  instance)*  another  (not  necessarily  from 
the  same  manufacturer ) moved  into  its  place*  and  the 
same  program  executed  without  reteaching  it  with  the 
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new  robot.  If  several  robots  were  to  perform  the  same 
task  in  identical  work  areas«  all  of  them  could  execute 
copies  of  the  same  program.  This  would  be  possible 
since  the  task  program  would  specify  the  end  points  of 
the  various  motions  in  a robot-independent  workspace 
coordinate  system  which  would  describe  the  desired  po- 
sitions and  orientations  of  the  end  effector.  These 
positions  and  orientations  are  a function  of  the  task 
and  the  workspace  geographical  layout/  not  the  joint 
configuration  of  the  robot.  The  tailoring  of  these 
programs  to  a particular  robot  would  occur  within  the 
manufacturei — supplied  controller.  The  robot- 
independent  trajectory  coordinates  could  be  fed  in 
through  the  proposed  interface/  transformed  into  joint 
values  for  that  robot#  and  executed. 


If  the  output  of  the  reverse  transf ormation  (namely 
from  the  joint  space  coordinates  of  the  robot  back  to 
the  same  robot-independent  coordinate  system  such  as 
Cartesian  coordinates)  were  made  available  through  this 
interface/  then  a task  program  could  be  taught  on  one 
robot#  the  robot— independent  form  of  the  trajectory 
points  stored  external  to  the  controller#  and  executed 
on  any  other  suitable  robot. 

2.  Optimized  vontrol 

This  type  of  interface  would  also  provide  the  user  the 
option  of  generating  specialized  trajectories  tailored 
to  the  particular  needs  of  the  task#  thus  allowing  tra- 
jectory control  capabilities  not  available  from  the 
manufacturer.  The  following  are  examples  of  capabili- 
ties that  would  become  possible;  special  accelerat ion- 
deceleration  profiles#  passing  through  intermediate 
path  points  according  to  some  desired  smoothing  algo- 
rithm# displaying  controlled  motion  through  some  par- 
ticular coordinate  reference  frame#  moving  about  an  end 
effector  that  is  offset  from  the  end  plate  of  the  robot 
in  some  unusual  manner#  programming  tasks  through  a 
type  of  joystick  input  specialized  to  some  optimal  user 
coordinate  reference  system#  varying  tolerance  specifi- 
cation on  how  close  the  robot  must  come  to  a programmed 
point  before  executing  the  next  point#  using  special- 
ized approach  and  departure  paths#  etc. 

This  interface  being  discussed  supplies  the  controller 
with  the  executable  trajectory  points  in  a real-time 
manner.  It  essentially  allows  complete  external  control 
over  the  motions  of  the  robot  on  an  instant-by-instant 
basis  where  the  type  of  control  is  only  limited  by  the 
user's  algorithms  processed  in  the  user-supplied  exter- 
nal computing  syst^em. 
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3.  Sensory  Feedback  Interaction 


Goal— directed  behavior  refers  to  the  capability  of  a 
robot  to  carry  out  a programmed  task  in  spite  of  small 
perturbations  in  its  environment  that  would  normally 
lead  to  incorrect  behavior  in  a simple  teach-record- 
playback  type  of  robot.  An  example  of  this  is  the  ac- 
quisition of  a part  on  a conveyor  that  has  some  arbi- 
trary rotation  and  placement  on  the  belt.  In  order  for 
the  robot  to  acquire  this  part#  certain  information 
must  be  made  available  to  the  control  system  to  produce 
the  corrective  trajectory  modifications  necessary  to 
cope  with  the  situation  and  to  pick  up  the  part.  This 
requires  sensors  to  measure  the  conditions#  computing 
systems  to  process  the  data  into  a proper  form#  and  a 
control  system  to  make  trajectory  modifications  in 
real-time  in  order  to  accomodate  these  conditions.  If 
the  manufac turer 's  controller  does  not  perform  these 
functions  or  does  not  have  the  necessary  type  of  inter- 
faces to  allow  sensor  input  or  external  control  of  the 
robot#  then  the  robot  will  not  be  able  to  exhibit  this 
real-time  sensory  interactive  behavior. 
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If  an  interface  into  the  robot  cont 
that  trajec  toi*y  points  can  be  ir 
source  and  executed  by  the  controller 
then  the  user  has  the  option#  by 
processor  and  this  interface#  of 
feedback  data  to  control  the  robot's 
must  provide  the  sensor#  the  sensory 
the  control  system  algorithms  for  trajectory  generation 
based  on  the  sensory  data.  The  output  of  this  user- 
supplied  system  is  a set  of  trajectory  points  in  some 
defined  robot-independent  coordinate  reference  frame. 
These  values  pass  into  the  controller#  are  transformed 
into  the  joint  space  of  the  robot#  and  sent  to  th(?  ser- 
vo system  to  execute  the  proper  motions  on  the  robot. 


Thus#  this  type  of  interface 
of  having  the  robot  interact 
sor  the  user  might  desire  to 
cation. 


would  provide  the  option 
in  real-time  with  any  sen- 
use  in  a particular  appli- 


4.  Off-line  Programming 


In  general# 
robot  task, 
by  leading  it 
recording  each 
ecut ion. 


there  are  two  methods  of  programming  a 
With  one#  the  robot  is  “taught"  the  task 
the  necessary  locations# 
back  in  sequence  during  ex- 


through  all 
to  be  played 


The  other  method#  called  off-line  programming#  creates 
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a task  description  without  the  necessity  of  using  the 
robot^s  actual  motion  through  those  locations.  This 
programming  is  a-ccomp  1 ished  in  much  the  same  manner  as 
a computer  program  is  written.  A procedural  descrip- 
tion is  generated  indicating  the  flow  of  control  with 
various  branching  conditions.  The  actual  location 
values  can  be  entered  in  a number  of  possible  ways. 
These  trajectory  location  values  are  stored  in  some 
robot-independent  form  (for  example^  coordinate  values 
in  a Cartesian  reference  frame).  They  may  have  been 
entered  by  typing  the  values  into  a terminal;  having 
some  program  generate  them*  such  as  might  be  done  with 
the  locations  in  a palletized  array;  accessing  an  al- 
ready existent  data  base  (such  as  might  be  done  with 
the  locations  of  holes  to  be  drilled  in  a wing  skin« 
the  positions  of  which  are  already  stored  in  some 
CAD/CAM  (Computer  Aided  Design/Computer  Aided  Manufac- 
turing) system);  leading  a robot  physically  through  the 
task  and  having  the  robot-independent  form  of  the  coor- 
dinates calculated  from  the  reverse  coordinate 
transf ormat ion  of  the  joint  position  values.  The  im- 
portant -concept  here  is  that  since  the  trajectory  loca- 
tions are  stored  in  terms  of  a robot-independent  set  of 
coordinate  values*  they  can  come  from  a number  of 
sources  and  can  be  used  to  control  execution  of  the 
programmed  task  on  any  robot  with  sufficient  physical 
and  performance  capabilities. 

Since  these  values  are  not  dependent  on  a specific 
robot*  they  can  be  generated  and  manipulated  "off- 
line*" without  the  robot*  and  used  in  an  integrated 
computer-aided-manufactur ing  environment  where  the  exe- 
cution of  these  programmed  trajectories  can  be  accom- 
plished by  any  number  of  robots.  The  user  is  thus 
given  the  capability  to  do  real-time  scheduling*  where 
jobs  can  be  routed  to  alternate  workstations  and  the 
robot-independent  trajectories  down-loaded  to  whichever 
robot  is  available  in  that  workstation. 

Clearly*  the  robot-independent  control  interface  great- 
ly aids  in  the  imp lemelitat ion  of  a flexible*  integrated 
system.  It  also  forms  a very  necessary  part  of  an  ef- 
fective "off-line"  programming  capability. 

To  fully  realize  the  benefits  of  programming  tasks  by  a 
procedural  description  of  what  is  desired  to  be  accom- 
plished* it  is  necessary  to  he  able  to  describe  the 
tasks  independent  of  which  particular  robot  may  he 
used.  This  is  only  possible  if  the  programs  can  refer- 
ence task  positions  and  orientations  in  a form  that  is 
dependent  on  the  required  action*  but  not  dependent  on 
a particular  robot's  joint  configuration.  If  this  type 
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of  robot  independence  is  not  available*  every  robot  in 
every  workstation  would  have  to  be  led  through  every 
possible  set  of  actions  that  tuight  be  performed  at  that 
workstation  by  that  robot*  and  the  joint  values  of 
every  robot  of  every  workstation  for  every  one  of  these 
positions  will  have  to  be  recorded.  This  programming 
effort  is  enormous*  cumbersome*  time  consuming*  inef- 
fective* unstructured  in  its  approach*  tedious  to  main- 
tain* and  leads  to  unreliable  and  less  than  optimum  use 
of  the  robots. 

To  reach  a truly  flexible  integrated  computer-aided- 
manufac  tur  ing  system*  robots  will  have  to  become  gen- 
eral purpose*  interchangeable  modules  with  a common* 
well-defined  interface  into  the  rest  of  the  system. 
Robot-independent  task  descriptions  (trajectory  points) 
will  be  passed  through  this  interface  to  be  transformed 
by  the  robot's  controller  computer  into  the  appropriate 
joint  values  needed  to  execute  the  tasks. 

D.  Users  of  Real-Time  Control  Interfaces 

The  general  consensus  of  the  working  group  was  that  at  the 
present  time  there  would  be  a small  number  of  potential 
users  of  tnis  optional  robot  control  interface  if  it  were 
available.  Most  users  would  want  to  employ  the  robot  in 
stand-alone  applications  where  only  the  capabilities  sup- 
plied by  the  manufacturer  would  be  needed*  and  programming 
each  and  every  task  by  the  teach-record-p laybac k technique 
would  not  be  considered  a problem. 

Even  though  it  was  felt  that  the  number  of  potential  users 
was  small*  it  was  noted  that  they  would  be  mostly  the  large 
manufacturers  and  therefore  represent  a sizeable  number  of 
installations.  Several  of  these  major  manufactur ing  com- 
panies have  already  set  up  their  own  internal  research  ef- 
forts in  this  area  as  part  of  an  overall  program  of  upgrad- 
ing and  automating  their  manufactur ing  process.  The  comput- 
er is  the  underlying  component  of  this  effort  in  robotics* 
which  is  just  one  aspect  of  the  overall  goal  of  the  in- 
tegrated computer -aided-manufac tur ing  system.  The  research 
effort  to  produce  an  easily  programmab le*  flexible*  automat- 
ed manufactur ing  cell  is  directed  towards  this  end.  The 
robot  is*  of  course*  an  important  element  in  this  system* 
but  system  integration  requires  well  defined  interfaces. 
For  these  research  efforts  to  take  full  advantage  of  the  so- 
phisticated control  and  sensory  interactive  behavior  possi- 
ble with  advanced  computing  systems*  the  robot  cannot  be  a 
stand-alone  device  without  any  method  for  the  user  to  inter- 
face to  it  to  enhance  and  tailor  its  capabilities  to  the 
user's  particular  tasks.  This  type  of  robot-independent  in- 
terface specif ication  is  one  of  the  necessary  first  steps 
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req.uired  in  the  del^inition  of  a set  of  appropriate  inter- 
faces between  robots  and  external  computing  systems  provid- 
ing sensory  data#  control#  access  to  other  data  bases#  and 
overall  integration  of  the  system. 

In  general#  users  of  this  type  of  interface  would  be  those 
involved  in  research  and  development  of  integrated  systems 
using  robots.  Ihis  also  includes  third  party  vendors  who 
would  develop  and  install  robot  systems  in  companies  that 
did  not  have  their  own  company  based  research  effort  in  this 
area#  as  well  as  vendors  that  would  supply  different  com- 
ponents such  as  a vision  sensor  module.  This  type  of  inter- 
face would  considerably  ease  the  task  of  integrating  user- 
defined  capabilities  and  sensory  interactive  behavior  into  a 
turn-key  system.  Vendors  could  develop  their  own  retrofit 
packages  providing  users  the  ability  to  purchase  the  com- 
ponents required  for  the  particular  application#  and  essen- 
tially plug  them  together  to  produce  the  desired  system.  A 
user  could#  for  instance#  buy  a robot  from  one  manufacturer 
and  a vision  system  from  another  and  connect  them  to  allow 
the  robot  fro  perform  part  acquisition  of  misoriented  parts. 

Thus#  while  the  number  of  users  who  might  make  use  of  this 
interface  directly  is  currently  small#  the  number  of  appli- 
cations could  be  considerable. 

E.  Control  Level  of  the  Interface 

Possible  interfaces  into  each  of  three  different  levels  of 
control  were  discussed.  (See  Fig  4.  ) These  were  the  servo 
level#  the  coordinate  transf ormat ion  level#  and  the  trajec- 
tory generation  level.  The  coordinate  transf ormat ion  level 
was  thought  to  be  optimal  for  this  interface  at  the  present 
time  since  it  provided  a fairly  simple  and  straight  forward 
control  specification  while  being  the  lowest  level  that  this 
specification  could  still  be  robot-independent.  The  follow- 
ing is  a brief  description  of  the  advantages  and  disadvan- 
tages of  interfacing  to  the  three  previously  mentioned  lev- 
els of  control. 


An  interface  into  the  joint  servo  system 
control  of  the  robot  but  would 
the  coordinate  transf ormat ion 
would  also  be  robot— dependent 
given  position  and  orientation  of  the  robot 
each  robot. 
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It  was  felt  that  a more  likely  level  for  the  interface  was 
at  the  control  level  above  this#  namely  the  level  at  which 

transformed  from  some 
the  joint  values  for  the 
Most  manufacturers  will 


the  robot  trajectory  points  are 
workspace  oriented  coordinates  into 
individual  actuators  of  the  robot. 
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eventually  supply  this  capability  on  their  controllers  for 
the  ease  in  programming  and  trajectory  control  it  affords. 
The  interface  into  these  transf ormations  is  rather  simple 
and  well-defined  and  provides  the  user  the  option  of  com- 
plete real-time  trajectory  control  of  the  robot.  At  the 
same  time#  it  offers  the  advantage  of  robot-independent 
specification  of  robot  motions#  with  all  the  benefits  previ- 
ously described. 

A number  of  the  participants  expressed  an  interest  in  an  in- 
terface at  a high  level  in  the  control  system.  Only  trajec- 
tory end-points  would  be  entered  through  this  interface# 
while  the  robot's  controller  would  provide  the  trajectory 
generation#  acceleration  and  deceleration#  path  control# 
etc.  The  consensus  of  the  group  was  that  this  would  prob- 
ably be  a desirable  interface#  but  at  the  present  time  it 
would  be  more  difficult  to  define  due  to  different  ways  tra- 
jectories can  be  generated#  the  various  possible  formats 
used  by  different  manufacturers#  and  the  rather  unclear  view 
of  how  to  specify  sensor  interaction  at  this  level.  Howev- 
er# it  was  felt  that  as  experience  is  gained  with  the  more 
sophisticated  control  systems  becoming  available#  an  inter- 
face at  this  level  should  definitely  be  reconsidered  in  the 
future. 

Again#  the  result  of  this  area  of  discussion  was  that  the 
input  at  the  coordinate  transf ormation  level  seems  the  most 
likely  place  for  a common  interface  since  it  provides  the 
lowest  level  of  input  to  the  robot  that  is  robot-independent 
while  affording  the  capacity  for  real-time  control.  It 
does#  however#  require  the  user  to  provide  all  the  program- 
ming# sensory  interaction#  and  trajectory-execution  calcula- 
tions on  user  supplied  computing  system  that  is  totally 
separate  from  the  robot  controller. 


IV.  SCOPE  OF  THE  INTERFACE 

The  spec  if ication  of  this  interface  has  been  partitioned 
into  two  parts.  One  deals  with  the  communication  aspect  of 
the  interface#  the  other  with  the  control  information. 

A.  Communication  Interface 

1.  Hardware 

There  was  general  agreement  that  a hardware  communica- 
tions interface  should  be  some  standard  computer-type 
interface.  There  is  certainly  no  need  to  duplicate  the 
efforts  that  are  presently  being  carried  out  in  the 
development  of  reliable  communications  hardware.  Of 
the  various  hardware  configurations  available 
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axis. 

Ihe  second  example  shows  the  same  end  effector  in  the  same  position  an 
orientation  but  specified  in  a spherical  coordinate  system.  An  x,y,z  loca 
tion  defines  the  position  of  the  end  point  in  the  workspace.  The  orienta 
tion  of  the  end  effector  is  specified  by  the  three  rotational  angles  shown. 
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ROBOT  TASK 

COMMAMO  INPUTS 

(e6.  GOTO  PART  ’A'- grasp') 


TRAJECTORY  POINTS  iN 
workspace.  COORDINATES 
^EG.  X.  Y.Z.  d).  Tk.-©") 


TRAJECTORY  POINTS  IN 
JOINT  SPACE  COORDINATES 
CeG.  Jl,ja  . J3,  JG) 


drive  signals 
TO  ACTUATORS 


FIG  4 Schematic  modularization  of  Robot  Control  System 
depicting  possible  interface  locations  for  external  con- 
trol signa Is . 


(paralleli  seriali  and  netuiork)^  the  serial  type  seems 
most  applicable  since  it  requires  few  lines#  can  com- 
municate over  long  distances#  and  has  sufficient  data 
rate  capability.  The  amount  of  data  to  be  transferred 
through  this  interface  is  relatively  small.  A suggest- 
ed data  rate  was  19.2  kilobaud.  This  seems  applicable 
since  specif ication  of  a robot  location  in  an  arbitrary 
coordinate  system  is  assumed  to  require  nine  values# 
each  having  16  bits  of  precision.  An  update  rate  of 
100  Hz  was  hypothesized  yielding  1600  bits  per  second 
of  data.  This  was  multiplied  by  10  to  allow  for  other 
control  information  and  communication  protocol  overhead 
giving  16000  bits  per  second  (baud).  The  next  highest 
“standard**  data  rate  is  19.2  kilobaud#  so  it  was  chosen 
as  a desirable  value. 

2.  Protocol 

It  was  suggested  that  the  communications  links  should 
take  advantage  of  the  new  LSI  (large  scale  integration) 
communication  circuitry  that  offers  a large  amount  of 
user  transparent  protocol  and  error  detection.  Small 
chip  sets  have  sophisticated  protocol  routines  that 
essentially  guarantee  error-free  communications  by  do- 
ing extensive  error  checking  on  the  incoming  data 
stream  and  allowing  rebroadcast  from  the  sender  if  an 
error  is  detected.  Much  of  this  protocol  is  handled  in 
the  communications  system  with  relatively  small  over- 
head requirements  on  the  processors  at  either  end  of 
the  link. 

B.  Control  Information  Interface 

This  interface  is  specified  by  the  information  to  be  passed 
through  it.  The  following  describes  the  type  of  information 
that  was  thought  to  be  necessary  and  whether  it  was  to  be  in 
the  form  of  a standard  interface  or  specified  by  the  robot 
manuf ac  tur er . 


1. 


Inf ormat i on 


Content  and  Structure 


It  was  decided  that  the  information  should  be  a se 
coordinate  values  sufficient  to  fully  describe  th 
degrees  of  freedom  of  an  end  effector  on  the  r 
(For  example#  this  could  be  done  by  specifying  th 
sition  and  orientation  of  a mounting  face  plate  on 
end  of  the  robot  arm. ) These  coordinate  values  wou 
in  some  robot-independent  coordinate  system#  sue 
Cartesian  or  spherical.  (See  Fig  5.  ) It  was  also  a 
that  the  particular  coordinate  reference  frame  t 
used  should  be  specified  by  the  robot  manufacturer 
long  as  the  robot  locations  are  specified  in 
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robot-independent  coordinate  system*  it  is  not  impor- 
tant which  coordinate  system  is  used.  Any  user  with 
enough  expertise  to  take  advantage  of  this  interface 
would  have  sufficient  understanding  of  the  control  sys- 
tem t-o  be  able  to  easily  generate  a post-processor 
type  of  software  module  (see  Fig  6)  to  transform  the 
location  values  in  some  user-defined  coordinate  system 
into  the  coordinate  system  specified  by  the  manufactur- 
er. The  user  would  only  need  to  write  one  of  these 
post— processors  for  each  robot  manufacturer*  not  one 
for  each  robot.  All  the  robots  of  one  manufacturer 
type  would  use  the  same  post-processor. 


The  location  values  would  represent  absolute  coordi- 
nates* as  opposed  to  delta  offset  values  from  the  last 
set  sent  to  the  robot.  This  interface  essentially  pro- 
vides a switch  (see  Fig  7)  that  chooses  either  the 
manufac turei‘ 's  control  system  or  the  user-supplied  con- 
trol system  to  input  the  robot-independent  form  of  the 
trajectory  coordinates  into  the  coordinate  transforma- 
tion level  in  the  robot  controller.  This  interface 
would  be  a two-way  link  in  that  the  coordinates  speci- 
fying the  next  desired  position  and  orientation  would 
pass  through  to  the  robot  contoller  and  the  coordinates 
describing  the  actual  position  and  orientation  would 
come  back  from  the  controller's  reverse  transf ormat ion. 
having  been  calculated  from  the  present  joint  position 
values  of  the  robot. 

Even  though  these  coordinates  specify  position*  veloci- 
ty and  acceleration  can  be  generated  by  varying  the 
spacial  distance  between  specified  locations.  (See  Fig 
8.  ) Given  a constant  time  interval*  velocity  is  detei — 
mined  by  the  length  of  the  commanded  motion  at  each 
new  update.  For  example*  if  the  update  rate  is  30  Hz 
and  the  coordinate  values  input  to  the  interface  speci- 
fy a 1.0  cm  motion  during  each  update  cycle*  then  the 
resulting  velocity  is  30  cm/sec  (1.0  cm/cycle  * 30 
cycles/sec  - 30  cm/sec).  If  the  coordinate  values  call 
for  a 2.  0 cm  move  each  time*  then  the  velocity  would  be 
60  cm/sec. 


If  the  length  of  the  motion  sp 
values  is  different  for  each 
or  deceleration  will  result, 
started  f)‘om  a stationary  po 
inputs  called  For  motions*  eac 
previous  motions  (that  is*  th 
for  a 0. 1 cm  motion*  the  secon 
the  third  for  a 0.3  cm  moti 
would  undergo  an  acceleration 
value  is  avvived  at  in  the 
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FIG  7 This  figure  schematically  depicts  the  switching 
within  the  robot  controller  to  accept  trajectory  point 
input  either  from  the  manf acturer ' s supplied 
t each-execute  programs  or  from  the  user's  supplied  con- 
trol system  through  the  manufacturer’s  specified  robot- 
independent  interface.  The  user  has  post-processed  the 
trajectory  points  into  the  manufacturer's  defined  coor- 
dinate system  (in  this  example,  a spherical  coordinate 
system)  which  then  feeds  into  the  internal  coordinate 
transformation  algorithms  to  calculate  the  corresponding 
joint  values  for  the  particular  robot. 


FIG  8a  Plot  illustrating  calculation  of  two  example 
velocities  (30  cra/sec  and  60  cm/sec)  obtained  by  speci- 
fying position  values  at  constant  time  intervals  (1/30 
sec). 


DISTAHCE 

(CM) 


IMSTANTANEOOS 
VELOCITY 
( CM^'SCC) 


FIG  8b  and  8c  Example  showing  computation  of  instan- 
taneous velocities  (b)  obtained  from  steadily  increasing 
distance  moves  in  constant  time  intervals  (1/30  sec)  and 
the  resulting  acceleration  (c). 


the  last  update  period  of  the  first  second*  the  robot 
would  be  commanded  to  move  3.  0 cm  (30  updates*  each 
lengthening  the  motion  by  0.  1 cm*  for  a total  of  30  « 
0. 1 cm  ~ 3.0  cm)  during  that  particular  update  time 
period  for  an  i nstantaneous  velocity  of  90  cm/sec.  (3.0 
cm  in  1/30  of  a second  is  an  instantaneous  velocity  of 
3.0  cm/cycle  *■  30  cycles/sec  - 90  cm/sec.  ) During  the 
last  update  period  of  the  next  second*  it  would  move 
6.  0 cm  for  a velocity  at  that  instant  of  180  cm/sec. 
The  difference  in  instantaneous  velocities  from  one 
second  to  the  next  would  be  90  cm/sec.  (The  instantane- 
ous velocity  would  be  90  cm/sec  at  the  end  of  the  first 
second*  180  cm/sec  at  the  end  of  the  second  second*  270 
cm/sec  at  the  end  of  the  third  second*  etc.*  that  is* 
the  velocity  is  increasing  by  90  cm/sec  each  second 
giving  an  acceleration  of  90  cm/sec/sec.  > Thus*  by  con- 
trolling the  length  of  the  motions  called  for  by  each 
successive  set  of  coordinate  values*  both  velocity  and 
acceleration  can  be  specified  through  positional  data. 

This  positional  data  will  be  sent  to  the  interface  at  a 
fairly  high  update  rate  in  order  to  ensure  smooth  and 
stable  motion  from  the  robot.  The  actual  update  fre- 
q,uency  of  the  data  will  be  left  up  to  the  robot 
manufacturer  since  this  will  be  a function  of  the  speed 
of  the  coordinate  transf ormat ion  algorithms  in  the 
robot  controller.  In  general*  these  updates  will  be  in 
the  range  of  25  to  100  Hz.  Uhatever  rate  is  specified 
by  the  robot  manufacturer  will  be  a constant  for  opera- 
tion of  that  type  of  robot. 

2.  Data  Format  and  Precision 


Coordinate  values  can  be  represented  in  a 
different  data  formats  (integer*  floating-po 
It  was  decided  that  the  format  of  the  data 
specified  by  the  robot  manuf ac turer*  as  shou 
cision  of  the  data.  The  values  of  these 
must  be  at  least  as  precise  as  the  joint  pos 
cators  on  the  robot*  or  else  some  of  the  pve 
pability  of  the  robot  would  be  lost.  In  gen 
are  in  the  range  of  16-bit  integer  values. 


number  of 
int*  etc. ) . 

should  be 
Id  the  pre- 
coordinates 
itiori  indi- 
cision  ca- 
eral*  these 


V.  STANDARDIZA1 ION 

The  general  feeling  of  the  group  was  that  this  interface  was 
not  ready  to  be  standardized.  Standard i zat ion  requires  a 
total  specification  of  all  the  data*  in  structure*  format* 
precision*  communication  protocol*  etc.  It  was  felt  that 
this  would  be  too  restrictive  on  both  manuf ac turer s and 
users  at  this  time  since  the  total  requirements  on  this 
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interface  are  not  that  uiell  understood  yet.  It  was  also 
agreed  that  there  was  a.  much  better  chance  to  get  an  inter- 
face of  this  type  impletnented  by  the  manufac turers  if  they 
were  allowed  to  specify  the  interface  to  be  as  compatible  as 
possible  with  their  present  systems.  As  long  as  an  inter- 
face is  fully  specified*  and  the  coordinates  are  in  a 
robot-independent  form*  the  purpose  of  this  interface  would 
be  met.  As  mentioned  previously*  the  post-processing  re- 
quired to  transform  any  user-supplied  coordinates  into  a 
manfacturer 's-def ined  coordinate  system  is  a fairly 
straightf orward  task.  The  availablity  of  inexpensive  pro- 
cessing capability  has  somewhat  relieved  the  requirement  of 
a single  standard  interface  format*  since*  as  long  as  the 
information  is  completely  defined*  it  can  be  processed  by 
either  a user's  or  manufacturer 's  controller  into  the  re- 
quired form  for  the  robot  system. 

It  is  not  improbable*  however*  that  a standard  should  be 
formulated-  at  some  later  time*  after  enough  experience  has 
been  gained  concerning  this  interface  to  fully  specify  all 
of  the  necessary  requirements. 


VI.  TIhINO  OF  EFFORT 

It  was  felt  this  was  an  appropriate  time  to  consider  setting 
up  this  particular  interface*  but  too  early  for  a standardi- 
zation effort.  Several  robot  manufacturers  presently  offer 
sufficient  capabilities  in  their  controllers  that  this  in- 
terface could  be  introduced  as  an  optional  input  to  their 
robots.  As  other  robots  are  introduced  with  at  least  the 
real-time  coordinate  transformation  capabilities  in  their 
controllers*  it  is  hoped  that  these  workshop  efforts  will 
help  to  encourage  the  manufac turers ' inclusion  of  this  type 
of  interface. 

There  is  presently  a considerable  interest  and  the  begin- 
nings of  in-depth  programs  within  industry  and  government 
aimed  at  integrated  computer-aided-manufac tur ing  systems. 
The  objective  is  necessarily  dependent  on  a structured  sys- 
tems of  modular  elements  connected  by  well-defined  inter- 
faces. These  efforts  will  undoubtedly  help  to  emphasize  the 
need  and  the  requirements  for  these  interfaces.  Now  is  the 
time  to  consider  them  and  to  begin  their  implementation. 
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COMPLEX  SENSOR  INTERFACE 
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Unimat ion 
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II.  DEFINITION 


A complex  sensor  is  one  which  has  some  sort  of  preprocessor 
associated  with  it  that  performs  at  least  an  analog-to- 
digital  conversion  on  the  sensory  data#  and  usually  performs 
scaling#  filtering#  formatting#  analysis#  and  coordinate 
transf ormations  as  well.  The  preprocessor  is  typically 
realized  in  the  form  of  a microprocessor.  A complex  sensor 
communicates  with  the  robot  control  system  by  means  of  digi- 
tal signals. 

III.  NEEDS  AND  SCOPE 

The  need  for  complex  sensors  is  obvious.  Present  day  indus- 
trial robots  are  d.eaf#  dumb#  blind#  and  have  little  or  no 
sense  of  force  or  touch.  In  order  for  a robot  to  interact 
with  an  even  slightly  unstructured  environment#  it  must  have 
the  ability  to  sense  errors  and  correct  trajectories  based 
on  sensory  measurements.  This  typically  requires  computa- 
tion by  the  sensory  data  channel  to  detect  features#  recog- 
nize patterns#  and  compare  observed  input  with  internal  ex- 
pectations. Usually  a coordinate  transf ormation  is 
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necessary  before  the  sensory  data  can  be  used  b 
system  for  modifying  the  behavioral  actions 
Certainly*  if  the  data  is  visual*  a great  deal 
tion  is  required  before  the  control  system 
make  decisions. 


y the  control 
of  the  robot. 

of  computa- 
can  use  it  to 


The  use  of  sensory  data  for  controlling  the  robot^s  actions 
implies  not  only  computation*  but  speed  of  response.  The 
robot  cannot  exhibit  high-speed*  closed-loop  performance  (as 
it  must  if  it  is  to  be  cost  competitive)  unless  the  response 
time  of  the  feedback  loop  is  short.  Decisions  cannot  be 
made  and  errors  cannot  be  corrected  until  the  feedback  in- 
formation arrives  at  the  control  center.  High-performance* 
closed-loop  stability  is  incompatible  with  loop  delays  of 
more  than  a feui  milliseconds. 


Sophisticated  use  of  sensors  and  efficient  processing  of 
sensory  data  also  requires  input  to  the  complex  sensor  from 
the  control  system.  Sensory  computations  need  to  have  in- 
formation as  to  uihat  action  is  being  performed  and  what 
response  is  expected  from  the  environment.  In  the  manufac- 
turing environment*  this  is  particularly  important  because 
so  much  is*  or  can  be*  known  about  the  environment.  The  vi- 
sion system  can  be  told  almost  exactly  what  to  expect.  It 
can  be  furnished  with  a model  of  the  parts  with  which  it 
must  deal.  It  can  even  be  told  where  they  are  (within  some 
tolerance).  The  vision  system  of  one  robot  can  be  given  a 
picture  of  what  a particular  part  looked  like  to  the  vision 
system  of  another  robot  that  just 
same  part.  Thus*  it  is  important 
two-way  between  the  control  system 
In  fact*  in  many  cases*  the  volume 


finished  handling  that 
that  the  communication  be 
and  the  complex  sensors, 
of  data  may  be  highest  in 


the  downward  direction* 
sory  processing  module. 


from  the  control  system  to  the  sen- 


There  are*  of  course*  many  kinds  o-f  complex  sensors.  Vision 
is  the  most  complex*  the  one  for  which  the  data  rates  are 
highest  and  the  processing  most  complicated*  but  force* 
touch*  and  various  proximity  sensors  can  be  extremely  so- 
phisticated as  well.  There  are  many  types  of  data  features* 
3-dimensional  models*  and  other  types  of  information  that 
must  flow  freely  and  rapidly  back  and  forth  across  the  sen- 
sory interface.  finally*  there  can  be  many  sensors*  or  many 
different  kinds  of  sensors*  on  the  same  robot  or  associated 
with  the  same  group  of  robots. 

These  being  the  needs*  the  task  is  then  to  devise  the  most 
efficient*  simple*  reliable*  and  inexpensive  interface  stan- 
dard that  meets  these  needs.  It  is*  of  course*  important 
that  any  standard  for  complex  sensory  interfaces  not  impede 
the  development  of  any  sensor  technology  because  of  unneces- 
sary limitations  of  the  interface  itself. 
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IV.  THE  WORKSHOP  DISCUSSIONS 


Th0  complex  sensory  interface  subgroup  focused  its  discus- 
sions on  the  configuration  shown  in  Figure  1.  There  are« 
however*  other  possible  physical  configurations  than  the  bus 
structure  of  Figure  1.  There  is  the  star  configuration  of 
Figure  2 where  each  complex  sensor  communicates  with  the 
robot  controller  through  a separate  port.  This  simplifies 
the  protocol*  since  there  is  only  one  sensor  on  each  port* 
but  it  requires  a large  number  of  ports.  In  practice  this 
is  often  difficult  because  of  the  large  number  of  pin  con- 
nections required.  One  way  around  this  difficulty,  is  shown 
in  Figure  3*  where  the  robot  controller  communicates  through 
a single  port  to  a multiplexer  which  provides  the  required 
number  of  ports.  A variation  on  the  bus  configuration  is 
the  ring  structure  of  Figure  4*  which  has  the  advantage  of 
redundancy.  The  ring  can  be  broken  at  any  point*  and  the 
ring  becomes  a bus. 

While  some  complex  sensors  may  consist  of  nothing  more  than 
an  A/D  converter  and  data  communications  port*  it  was  as- 
sumed that  a great  majority  of  complex  sensors  would  contain 
a microprocessor  with  a program  and  a data  storage  area. 
Thus*  it  was  agreed  that  the  interface  should  provide  means 
by  which  process-to-process  communication  could  take  place. 

Figure  1 indicates  the  various  types  of  information  that 
need  to  flow  in  both  directions  through  the  complex  sensory 
interface.  Information  flowing  from  the  complex  sensors  to 
the  robot  controller  consists  of  highly  processed  informa- 
tion such  as  part  position  and  orientation*  part  classifica- 
tion or  ident if icat ion;  inspection  data  such  as  part  dimen- 
sions* surface  finish*  verification  of  the  presence  of 
holes*  etc. t force  or  touch  vectors*  or  even  matrices  indi- 
cating the  robot  motions  called  for  by  sensory  measurements. 

Information  flowing  from  the  robot  controller  to  the  complex 
sensors  is  of  the  form  of  commands  to  make  certain  measure- 
ments or  to  execute  certain  sensory  processing  algorithms; 
state  variables  indicating  what  action  is  being  executed  by 
the  control  system  or  by  other  systems  such  as  conveyors* 
robot  carts*  machine  tools*  etc;  or  even  expected  data  or 
parameters  such  as  images*  maps*  or  features  which  may  have 
been  derived  from  teaching  or  from  data  bases  containing 
part  character ist ics  and  process  plans.  The  downward  link 
from  robot  controller  to  complex  sensor  processor  may  also 
be  used  to  download  programs. 

This  implies  that  the  downlink  will  often  be  required  to 
convey  large  quantities  of  data.  In  most  cases  the  down- 
loading of  large  programs  or  data  bases  such  as  images  will 
not  be  done  during  program  execution*  but  will  take  place 
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FIGURE  1 


Basic  Configuration  of  a Complex  Sensor  System 


Additional  Sensors 


FIGURE  2 

Star  Configuration 


Additional  Sensors 


FIGURE  3 

Star  Configuration  using  a Multiplexor 


Additional  Sensors 


FIGURE  4 

Ring  Configuration 


before  the  robot's  operational  task  is  begun.  Thus»  the 
data  rate  need  not  be  sufficient  to  carry  out  large  block 
transfers  in  a fesi  milliseconds.  Nevertfieless*  it  is  possi- 
ble that  the  downloading  of  programs  or  data  mag  need  to  he 
done  frequently*  (for  example*  between  each  part  that  is 
presented  to  the  robot)*  so  the  data  transfer  may  need  to  be 
done  in  a few  seconds*  as  opposed  to  a few  minutes.  If  this 
is  the  case*  this  requirement  will  dictate  the  speed  of  the 
communications  link. 

It  was  assumed  that  the  robot  control  system  would  act  as  a 
master  and  the  complex  sensors  and  their  processors  would  be 
slave  devices.  It  was  generally  agreed  that  it  is  best  if 
the  robot  controller  polls  the  complex  sensors*  but  it  was 
understood  that  using  interrupts  may  be  required  by  some  ap- 
plications. Therefore*  the  communications  should  not  rule 
out  the  possibility  of  an  interrupt  driven  system. 

It  is  crucial  that  sensory  information  be  accessable  by  the 
program  in  the  robot  controller  in  an  efficient  and  timely 
manner.  It  was  noted  that  the  time  delays  that  could  be 
tolerated  could  vary  depending  on  the  type  of  data  and  the 
use  that  is  made  of  it  in  the  control  system.  Information 
required  for  tight  servo  loops  must  be  available  within  ten 
to  fifty  milliseconds.  This  is  the  turnaround-time*  which 
includes  the  time  required  to  send  the  command  requesting 
the  data  plus  the  time  required  to  collect  and  process  the 
data*  plus  the  time  required  to  transmit  the  results  of  the 
processing  to  the  robot  controller.  The  data  transmission 
rates  need  to  be  high  enough  to  support  this  entire  sequence 
for  as  many  sensors  as  are  required  to  respond  within  the 
loop  delay  period. 

Control  programs  must  not  only  be  able  to  test  and  branch  on 
complex  sensory  data  but  must  be  able  to  use  sensory  data  as 
arguments  in  functions  and  routines.  This  is  an  extremely 
important  requirement  which  does  not  presently  exist  on  any 
commercially  available  robot.  It  requires  that  the  inter- 
face at  the  robot  controller  have  some  means  by  which  com- 
plex sensory  data  can  be  inserted  into  memory  locations  ac- 
cessible as  arguments  by  the  robot  control  software. 
Without  this  feature  it  is  cumbersome*  if  not  impossible*  to 
cause  the  robot  to  move  in  the  direction  of  a sensed  force 
or  to  track  and  acquire  a visual  feature  on  a part.  Some 
existing  robot  controllers  allow  the  robot  to  be  commanded 
to  move  an  incremental  amount  in  x*  y*  z position*  but  not  in 
pitch*  yaw*  and  roll  rotation.  At  present*  however*  even 
this  is  not  easily  accomplished  through  a convenient  inter- 
face between  the  complex  sensor  and  the  data  locations  used 
by  the  robot  control  program. 

It  is  equally  important  that  commands  and  expected  data  from 
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CURRENT  STANDARDS  FOR 
COMPUTER-COMPUTER  COMMUNICATIONS 


1.  RS  -232C 

2.  RS  -449  (A  high-  speed  version  of  RS  -232C) 


3.  IEEE  583  This  runs  132  parallel  lines  at  20  - 800  kHz, 

with  a length  of  up  to  100  meters 

4.  IEEE  583  (CAMAC)  This  runs  2 or  4 serial  lines  at  20  - 800 

kHz,  with  a length  of  up  to  2 kilometers 

5.  IEEE  488  This  runs  24  byte-parallel  lines  at  1000  kHz, 

with  a length  of  yp  to  20  meters 

6.  MILSTD  155 3A  This  runs  2 serial  lines  at  100  kHz,  with 

a length  of  up  to  100  meters 

7.  MILSTD  1553B  (A  1000  kHz  version  of  MILSTD  155 3A) 


FIGURE  5 


the  robot  control  systen  be  available  to  the  programs  in  the 
complex  sensor  processor.  This  implies  that  the  complex 
sensor  have  a comparable  interface  by  which  information  and 
commands  from  the  robot  controller  can  be  easily  inserted 
into  the  data  locations  used  by  the  sensory  processing 
software. 


The  types  of  data#  types  of  communication  links 
standard  information  protocols  that  have  been  u 
lar  kinds  of  networking  in  the  past  were  discus 
felt  that  no  new  communications  systems  designs 
at  least  not  initially.  Presently  used 
computer-to-*computer  communication  were  felt  to 
The  table  in  Figure  9 list's  a number  of  presen 
tions  standards  that  were  felt  to  be  potenti 
for  a complex  sensor  interface. 


« and  various 
sed  for  simi- 
sed.  It  was 
were  neededi 
methods  for 
be  adequate, 
t communica- 
al  candidates 


As  a result  of  the  fact  that  complex  sensors  will  often  be 
required  to  work  in  a shop  environment  where  electrical 
noise  interference  is  a serious  and  ever-present  threat#  it 
was  felt  that  an  adequate  communication  protocol  must  in- 
clude some  form  of  error  detection  and  correction  pro- 
cedures. It  was  also  felt  that  fiber  optics  would  ultimate- 
ly be  the  communicat ions  medium  of  choice.  In  the  meantime# 
the  use  of  a single  coaxial  cable  was  felt  to  be  a desirable 
option.  However#  none  of  the  standard  systems  in  Figure  5 
work  with  a single  signal. 


V.  RECOMMENDATIONS 


It  was  concluded  that  it  is  too  early  to  recommend  any 
specific  standards  for  complex  sensory  interfaces.  At 
present  there  are  only  a few  commercially  available  robots 
with  complex  sensor  interfaces  of  any  kind#  and  these  inter- 
faces are  limited  in  utility  and  cumbersome  to  use.  Thus# 
there  is  very  little  as  yet  to  standard i z e.  Furthermore# 
there  are  too  few  persons  with  sufficient  experience  in  com- 
plex sensors  to  make  reasonable  recommendations  as  to  what 
such  standards  should  be.  However#  this  will  undoubtedly 
change  in  the  near  future.  Many  research  labs  and  robot 
users  are  pursuing  the  use  of  complex  sensory  data  in  robot 
control  systems.  *lhus#  an  experience  base  is  rapidly  being 
developed. 

Clearly  it  is  not  too  early  to  begin  discussing  the  require- 
ments and  suggesting  promising  approaches.  This  was  the 
purpose  of  the  workshop.  It  was  recommended  that  these 
preliminary  discussions  be  followed  up  with  additional 
workshops  and  that  contacts  be  established  with  the  ap- 
propriate standards  organ! zat ions  so  that  complex  sensory 
interface  standards  can  be  developed  as  soon  as  that  would 
be  practical.  This  is  an  area  where  interface  standards 
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might  be  a pouierful  force  in  creating  a market  for  complex 
•eneors.  An  interface  standard  would  allow  manuf ac turers  to 
develop  a single  product  that  could  be  used  on  a wide 
variety  of  robot  types. 
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FUTURE  GUIDELINES  TOWARDS  INTERFACES 


I.  GROUP  MEMBERS 


Nagel«  Roger  N.  * - 

VanderBrug*  Gordon*  - 
Albus«  James  S.  - 

Ames*  Carl  V.  - 

Baird*  Henry  S.  -- 

Barbera*  Anthony  J.  - 

Brower*  William  S.  - 

Colleen*  Hans  - 

Dunne*  Maurice  ~ 

Ennis*  Jerry  - 

Mei*  Lori  — 

Makhlin*  A.  G. 

Mayer*  Gordon  - 

Neuilin*  Burt  - 

Plumley*  Wally  *- 

Sheehan*  Joe  - 

Smith*  Bradford  M.  - 

Snowdon*  A1  *- 

VanderBrug*  Gordon  - 

Walker*  Jerry  -* 

Wiley*  Jack  -* 

* Co-Chairperson 


National  Bureau  of  Standards 
Automat ix 

National  Bureau  of  Standards 

General  Dynamics 

RCA 

National  Bureau  of  Standards 

Control  Data 

ASEA 

Unimation 
McDonnell  Douglas 
SME 

Westinghouse 

Wr  igh t-Patterson 

Department  of  Defense 

Loc k heed— Georgia 

Naval  Ship  R&D  Center 

National  Bureau  of  Standards 

Eaton  Corp. 

Automat ix 
Nor d son 

John  Deere  & Co. 

<NBS  Planning  Office) 


II.  INTRODUCTION 


The  workshop  sessions  on  Future  Guidelines  towards  Inter- 
faces were  specifically  charged  with  discussing  language* 
system  integration*  and  database  considerations  in  the  fu- 
ture of  robotics.  It  was  a ground  rule  of  the  discussion 
group  that  the  time  was  too  early  for  standards  efforts  by 
the  very  nature  of  the  topic  areas.  However*  the  directions 
and  trends  of  the  future  of  robotics  were  discussed  with  an 
eye  towards  the  need  for  future  standards  and  comments  on 
standards  were  reflected  throughout  the  discussions.  It  be- 
came clear  early  in  the  discussion  that  it  was  difficult  to 
separate  the  robot  of  the  future  from  the  factory  of  the  fu- 
ture and  discussion  often  shifted  to  the  role  of  automation 
in  manufacturing  cells  and  factories  wherein  robots  played  a 
significant  role.  It  was  conjectured  that  the  role  of  the 
robot  in  the  factory  of  the  future  was  not  as  an  individual 
component  but  as  a part  of  the  system.  The  session  leaders 
made  a strong  attempt  to  focus  the  discussion  around  robots 
in  the  factory  of  the  future  and  stand-alone  robot  systems 
of  the  future. 
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The  discussions  that  took  place  at  the  two  sessions  covered 
not  only  the  three  areas  of  language#  systems  integration# 
and  databases  but  also  languages  for  the  factory#  systems 
debugging#  and  robot  requirements  in  the  future.  In  the 
write-up  which  follows#  discussions  are  summarized  for  each 
of  the  six  topics. 

III.  SYNOPSIS  OF  GROUP  DISCUSSIONS 
A.  Robotic  Languages 

The  group  felt  that  the  current  method  of  teaching  robots 
via  a teach  box  would  be  replaced  in  the  future  by  off-line 
programmming  languages*  “off-line"  in  this  context  meaning 
without  the  robot  carrying  out  the  commands  in  real-time# 
but  not  without  a terminal  and  an  interactive  language  pro- 
cessor. Language  can  broadly  be  categorized  as  the  user  in- 
terface to  the  control  system  of  the  robot.  The  general  per- 
ception of  the  group  was  that  robotic  Languages  as  found  to- 
day can  be  put  into  two  broad  categories:  explicit  languages 
and  implicit  languages.  An  explicit  language  is  one  in  which 
one  talks  about  the  robot  joints  and  positions.  Examples  of 
explicit  languages  include  VAL#  EMILY#  SIGLA#  and  UAYE.  Im- 
plicit languages  are  those  in  which  one  describes  the  tasks 
to  be  performed  rather  the  motions  through  which  the  robot 
will  pass.  Examples  of  implicit  languages  are  AL#  ROBOT  APT* 
AUTO  PASS#  RAPT#  and  MAL.  There  was  a general  discussion 
about  the  fact  that  the  two  categories  defined  above  were 
rather  broad.  In  actuality#  several  levels  exist  within  each 
of  the  categories#  and  there  could  be  some  disagreement 
about  the  categor i z.ation  of  a particular  robot  programming 
language.  Because  oP  the  fact  that  most  of  the  languages 
described  above  are  not  broadly  available  and  that  the  group 
did  not  have  significant  experience  with  several  of  them#  it 
was  decided  that  it  would  be  more  important  to  talk  about 
the  desirable  attributes  of  languages  rather  than  go  through 
an  exhaustive  analysis  of  the  languages  themselves.  The 
group  postulated  the  following  as  desirable  attributes  for 
robot  languages. 

A language  for  programming  a robot  in  an  off-line  mode 
would  ideally  be  robot-independent.  It  should  be  a 
standard#  and  there  might  need  to  be  several  languages 
with  efforts  similiar  to  that  being  done  for  ROBOT  APT 
at  the  current  time.  The  language  must  allow  for  a 
hierarchy  of  control  and  exist  at  several  different 
levels  of  complexity.  The  language  should  have  provi- 
sion for  modifying  the  behavior  of  the  robot  due  to  the 
input  of  real-time  sensory  data.  The  Language  should 
have  good  interfaces  to  the  various  manufactur ing  and 
design  databases  found  in  a modern  manufac tur ing  en- 
vironment. Programming  of  the  robot  in  this  language 
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should  be  engineered  so  that  the  user  need  not  be  a 
computer  scientist  but  rather  someone  involved  in  the 
manufactur ing  process.  The  language  must  have  provi-- 
sions  for  system  verification  or  debugging  of  the  robot 
program  a-s  created  at  a terminal.  Examples  of  this 
would  be  a graphic  simulation  of  the  robot  program. 
Robot  programs  should  not  be  made  robot  specific  until 
the  program  is  ready  to  be  executed.  That  is«  it  should 
be  symbolic  until  the  time  of  execution.  Post- 
processors for  particularized  robots  should  be  created 
in  order  to  allow  the  language  to  be  independent  but 
available  for  a variety  of  robots. 

The  group  concluded  that  the  several  efforts  on  robot 
languages  should  continue  and  that  others  would  most  prob- 
ably surface.  At  the  current  time  it  is  far  too  early  to  be- 
gin a standard i zat ion  process  on  any  one  particular 
language.  However*  as  experience  is  gained  in  the  use  of 
these  languages*  some  of  them  will  naturally  come  forward  as 
standards  of  the  industry. 

B.  Systems  Integration 

The  group  felt  that  robots  will  naturally  be  imbedded  into 
the  factory  of  the  future.  The  key  concepts  with  respect  to 
the  integration  of  robots  into  the  factory  of  the  future  are 
the  accessing  by  robot  programs  of  the  databases  found  in 
computer-aided  design  systems  and  the  passing  of  control  in- 
formation that  needs  to  be  used  by  robot  programs  in  works- 
tations and  higher-order  factory  constructs.  In  both  of 
these  interface  areas  it  was  felt  that  there  is  not  yet 
enough  industrial  experience  to  define  standard  interfaces. 
However*  key  issues  wera  identified  with  respect  to  robots 
accessing  databases  in  the  manufacturing  and  design  arena. 

It  was  pointed  out  that  it  will  be  necessary  for  designers 
to  indicate  the  view*  pick-up  points*  and  other  parameters 
about  a part  being  designed  that  are  relevant  to  the  robot 
manipulating  that  part.  This  requires  the  robot  to  have  ac- 
cess to  the  descriptive  geometry  and  part  description  infor- 
mation created  by  the  part  designer.  With  respect  to  con- 
trol information*  the  simplest  method  of  passing  it  to  a 
robot  from  a higher-order  construct  would  be  in  robot- 
independent  position  coordinates*  using  standardized  terms 
and  commands  that  could  have  meaning  to  multiple  vendors' 
robots.  In  addition  to  control  information*  the  robot  will 
have  to  interact  with  other  sensors  in  the  automated  facto- 
ry. Because  parts  of  these  topics  were  covered  in  the  com- 
plex sensor  sessions*  the  group  did  not  linger  on  this  to- 
pic. 
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C.  Databases 


As  uias  reported  above*  databases  and  the  interface  of  robot 
programs  to  databases  are  important  concepts  if  me  are  to 
integrate  robots  into  higher-order  factory  systems.  In  par- 
ticular* it  was  felt  that  the  database  interface  was  criti- 
cal to  creating  a systems  hierarchy  for  a manufacturing 
cell.  Potential  database  interfaces  were  identified  in 
several  areas. 

1.  A manufac turing  database. 

2.  Inventory  of  parts  and  equipment. 

3.  Shop  floor  database. 

4.  Scheduling. 

5.  NC  databases. 

6.  Process  planning  databases. 

7.  Design  databases. 

The  group^s  conclusion  with  respect  to  databases  was  that 
the  concepts  required  in  databases  had  impact  on  the  ability 
to  integrate  robots  into  higher-order  systems  and  on  the 
design  of  robot  programming  languages.  The  group  concluded 
that*  as  the  use  of  robots  becomes  more  complex  and  robots 
take  on  higher-order  tasks  in  the  factory  manufacturing  en- 
vironment* they  will  by  necessity  need  access  to  several  of 
the  databases  outlined  above  in  order  to  carry  out  their 
tasks. 

D.  Languages  for  the  Factory 

The  group  discussed  the  language  for  control  of  an  automated 
manufacturing  operation  and  spent  a good  deal  of  time  trying 
to  define  tha  levels  in  a factory.  There  was  excellent 
agreement  on  the  fact  that  a factory  was  organized  into  a 
set  of  hierarchical  components.  There  was  significant 
disagreement  on  the  identification  of  each  of  these  levels. 

Figure  1 shows  the  levels  as  perceived  by  the  group  in  the 
ICAM  terminology.  The  process  is  the  lowest  level  in  the 
ICAM  terminology  and  represents  the  carrying  out  of  a par- 
ticular task.  Above  the  process  is  a workstation  which 
coordinates  the  efforts  of  several  processes.  Above  the 
uior kstation  is  a cell*  above  the  center*  and  above  that*  a 
factory.  Typical  commands  for  the  bottom  three  levels  of 
this  hierarchy  have  been  depicted  in  the  figure. 

As  the  group  attempted  to  state  commands  for  the  center  and 
the  factory*  it  became  clear  that  there  was  some  disagree- 
ment as  to  the  exact  definitions  of  these  levels.  The  group 
was*  however*  able  to  label  several  processes  which  go  on 
across  some  of  the  higher-order  levels*  and  they  have  been 
included  in  Figure  1.  The  general  conclusion  was  that  a 
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factory  would  be  organized  into  a hierarchy  similar  to  that 
used  in  the  ICAH  terminology. 

As  part  of  the  discussion  on  hierarchical  organizations!  the 
group  examined  the  hierarchy  for  the  NBS  robot.  The  NBS 
hierarchy  has  a complex  task  at  the  highest  level#  breaking 
down  into  simple  tasks#  trajectory  calculations#  coordinate 
transf ormations#  and  finally  servo  commands.  It  was  felt 
that  the  NBS  experlance  with  this  hierarchy  substantiated 
the  concepts  expected  to  be  used  in  a modern  manufactur ing 
cell.  The  group  felt  that#  as  factory  plans  are  organized 
in  the  hierarchical  nature  and  as  they  begin  to  be  imple- 
mented# there  would  be  better  agreement  on  the  terminology 
and  commands  which  exist  at  the  different  levels  of  the  fac- 
tory. General  principles  that  the  group  agreed  upon  were 
that  the  organization  would  be  hierarchical#  that  it  will 
use  the  task  decomposition  approach#  irhat  all  the  levels  ex- 
ist at  each  moment  in  time  with  different  cycle  times  for 
up-dating#  that  each  level  in  the  hierarchy  has  its  own  com- 
mands or  input  language  which  could  be  carried  out  in  time- 
sequencing 'commands  and  inputs  into  lower  levels#*  and  that 
each  level  would  get  input  from  above  in  the  nature  of  com- 
mands and  from  below  in  the  nature  of  feedback. 

E.  Systems  Debugging 

The  topic  of  debugging  constantly  arose  in  the  sessions.  In 
particular#  the  availability  of  debugging  tools  in  the  fu- 
ture use  of  robotics  was  considered  to  he  extremely  impor- 
tant. The  need  for  debugging#  it  was  felt#  underscores  the 
essential  nature  of  establishing  well-defined  interfaces. 
The  use  of  graphics  at  the  manufactur ing  cell  level  was  con- 
sidered to  be  an  important  ingredient  for  debugging  off-line 
programming#  in  order  not  to  tie  up  resources  and  for  safety 
considerations  (for  both  people  and  equipment).  The  use  of 
graphics  will  require  an  interface  standard  to  allow'  graphic 
products  to  work  for  more  than  one  robot  and  more  than  one 
robot  programming  language.  The  group  felt  that#  beyond  em- 
phasizing the  concept  of  building  in  debugging  tools  for 
off-line  robot  programming  languages#  there  was  not  yet 
enough  experience  to  specify  distinct  or  direct  algorithms 
for  the  debugging. 

F.  Robots  of  the  Future 

The  general  consensus  of  the  group  was  that  robot  systems 
would  become  more  and  more  complex.  They  would  use  off- 
line# higher— order  control  languages  as  well  as  employ  vi- 
sion and  other  complex  sensors.  They  would  have  robot- 
independent  programming  languages.  Robot  hardware  would  use 
standard  interfaces  to  the  language  modules  and  include 
post-processors  as  well  as  defining  robot-independent 
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position  commands.  Robot  software  would  allow  for  the  in- 
tegration of  the  robot  into  complex  factory  systems  or  for  a 
robot  with  a complex  array  of  sensors  to  be  used  as  stand- 
alone equipment. 

IV.  CONCLUSIONS 

In  summary#  the  Future  Guidelines  working  group  concluded 
that  robots  would  be  more  extensively  used  in  the  factory  of 
the  future.  Off-line  programming  languages  for  robots  and 
manufactur ing  cells  would  develop  in  a hierarchical  fashion. 
Advanced  prrogramming  Languages  will  need  to  be  robot- 
independent  and  should  provide  extensive  debugging  tech- 
niques in  an  off-line  mode.  Interfaces  will  need  to  be  de- 
fined for  robots#  databases#  control  systems#  and  complex 
sensory  devices.  In  addition#  hardware  interfaces  need  to 
be  defined  to  allow  for  smart  end  effectors  and  a variety  of 
hardware  connections  of  the  robot  to  its  environment.  The 
general  conclusion  of  the  group#  as  expected#  was  that  it  is 
currently  too  early  to  start  a standard i zat ion  effort  in 
these  areas.  However#  the  topics  should  be  reviewed  at  a 
future  conference#  in  order  to  measure  progress  and  stimu- 
late interest. 
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GENERAL  RECOMMENDATIONS  AND  CONCLUSIONS 


A group  session  s»as  held  on  the  last  day  of  the  workshop 
general  discussions  and  conclusions  by  the  full  group  on 
various  interfaces.  Each  session  chairperson  presente 
summary  of  their  group's  recommendations  and  conclusi 
The  starting  up  of  a standards  effort  was  recommended 
both  the  Simple  Sensor  and  Wrist  Interfaces.  It  was 
that  both  had  progressed  to  a point  where  standards  coul 
implemented  without  impeding  any  developing  technology. 


for 
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felt 
d be 


The  Common  Robot  Control  and  Complex  Sensor  Interfaces 
chairpersons  reported  on  guidelines  towards  their  respective 
standards.  It  was  felt  that  the  Common  Robot  Control  Inter- 
face was  ready  to  be  implemented*  but  not  ready  to  be  stand- 
ardized. Standardi zation  would  require  a full  set  of  specif- 
ications as  to  data  type  and  rate*  protocol*  etc.  to  be 
agreed  upon*  and  was  felt  to  be  too  restrictive  on  users  and 
manufacturers  at  this  time.  The  Complex  Sensor  Interface 
chairperson  reported  that  at  present*  complex  sensors  were 
not  in  wide  use*  and  as  such*  also  not  ready  to  be  standard- 
ized. It  was  felt  that  further  discussions  should  be  held  at 
a later  date.  Both  chairpersons  recommended  a waiting 
period  for  technology  and  experience  to  develop  in  these 
areas  before  actual  implementation  of  a standard. 

The  Future  Guidelines  towards  Interfaces  chairperson*  having 
a rather  broad  area  of  topics  ranging  from  databases  to 
off-line  programming*  outlined  a list  of  desirable  attri- 
butes for  each  of  the  topic  areas.  As  most  areas  are  still 
developing  (or  are  virtually  non-existent  at  present)*  it 
was  recommended  that  each  topic  area  be  examined  again  in 
another  standards  workshop  to  be  held  in  mid-1981. 
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